High Availability free: Kemari at the XEN Summit Asia (Tokyo)
Big news from the Xen Summit in Tokyo in November 2008.
Below is the agenda:
| Welcome & Keynote | |
| Kernel Architecture | |
| Xen in Real Services |
|
| Administration Tool |
|
| Performance & Reliability |
|
| Kernel Security I | |
| Kernel Security II |
|
| Kernel I/O |
|
Beyond all the other very interesting interventions, I would like to highlight the Kemari project in the Kernel Architecture section. It is a project that was born in Japan in 2007 by a team made up as follows:
- Yoshiaki Tamura
- Yoshisato Yanagisawa
- Koji Sato
- Seiji Kihara
- Satoshi Moriai
In practice, we try to create a very powerful High Availability between Virtual Machines, let’s see for example the following two schemas of the project:
From these two schemes, it is evident that there is a synchronization mechanism between two identical virtual machines that are instantiated on two different physical machines. The result is that a user attached to the virtual machine does not notice that the physical machine that hosted the virtual machine is in hardware failure.
Let’s think about what High Availability has been for virtual machines so far, let’s see the HA of the VMware Infrastructure, if a hardware failure occurs the hearthbeat system between the clusters restarts the virtual machines hosted by the failed machine in other hosts, this means at least an automatic shutdown and fast reboot. Instead, let’s remember how Microsoft’s much better known and older active/passive clusters work, for example.
There are at least two physical machines with shared disks and a dedicated network. In the event of failure of the active node, the clustered services that are no longer responsive are immediately replaced by the services of the passive node started for the occasion, in this case there is no downtime of the business.
In the case of the kemari project, if we think that all the files of the virtual machine are resident on the shared storage of the clusters, and if we think about how the VMware VMotion works that transfers and synchronizes only the contents of the virtual machine memory from one node to another and we think of having two instances of the same virtual machine on two separate physical machines, one of these in a waiting, quiescent state, we only need to add the synchronization of the memory contents and a heartbeat to instantly migrate accesses to the other instance.
For those who don’t know, there is a paid third-party product that works with Vmware and Citrix XenServer that does more or less the same thing, this is everRun by Marathon and is integrated into the HA of Citrix XenServer 5.0.0.
